The Internet (and related networks) can be used to send e-mails, conduct business, automate machinery and perform data processing. Connected users can use the Internet to interact with other connected users and/or connected computer systems. While one user might intend to communicate with another user over the Internet, there might be a third party listening in on, or interfering with, the communication without knowledge and/or authorization of the users. A third party might also attempt to perform unauthorized operations over the Internet, such as accessing network resources in ways unintended by the provider of those network resources. Network computer security deals with making it more difficult for unauthorized third parties to understand or interfere with such communications and/or secure operations that involve such communications.
Consider, for example, a client-server system wherein an application involves client software interacting with server software. That client-server system can be made secure by requiring that the client software, the server software and the network between them remain within a closed, secure system. However, this is impractical for many applications, such as where the client and server are separated by a network that can be accessed by unauthorized third parties.
As used herein, operations are deemed “authorized” and “unauthorized” based on what the developer or supplier of a program performing those operations determines is authorized. Users are deemed “authorized” and “unauthorized” based on who a service provider determines is authorized for what. For example, using an online banking app to view one's own bank balance might be considered an authorized operation by an authorized user, whereas automating thousands transfers of small amounts of money from accounts of others or gathering personal data from accounts of others might be an unauthorized operation in the eyes of the developer of the online banking app and such a user might be considered, in the eyes the bank maintaining those accounts, an unauthorized user.
An insecure network can be addressed by securing the client, securing the server, and encrypting all traffic between the two. However, that is impractical in situations where the client is widely and publicly disseminated. For example, a popular mobile app might be made available to millions of potential users. At least some of those potential users might use their access to the client software to access the server in unauthorized ways, perhaps reverse engineering the application programming interface (“API”) that the client uses to interact with the server and then writing an unauthorized version of the client that performs operations not intended by the provider of the client-server system.
All API interactions between the client and the server might be encrypted in a way that obscures operations that occur between the client and the server, but if an endpoint app is compromised or replicated, the encryption does not prevent attacks that use such endpoint app.
Security of a network resource is often considered sufficient even if it is not impossible to breach, if the effort required to mount an attack on that network resource is raised high enough so that it is uneconomical to attack while being easy enough for authorized users to access. Therefore, absolute security is not necessary in many cases, and it is sufficient to increase the efforts/costs of access to the network resource in a way that makes it uneconomical for an organization to mount an attack on those network resources, while allowing authorized uses.
But one example of a client-server system is where a user has a device that runs a web client (such as an Internet browser), that web client communicates with a web server using the Hypertext Transport Protocol (“HTTP”) over the Internet. The web client might make a specific request of the web server by sending that web server a structured HTTP request and the web server might respond with an HTTP response comprising a Hypertext Markup Language (“HTML”) document, which the web client then “renders” to form a displayable form of the HTML document (e.g., a web page) viewable by the user of the web client (or the device executing a software web client). Other applicable protocols might include API calls that use HTTPS, JavaScript™, CSS, XML, JSON, or other forms of web traffic or web content.
Whether an API is explicitly provided for, or an implicit API results from the structured nature of HTML documents, authorized and unauthorized users can run machine-to-machine automated operations. Even with ways to secure an API, an unauthorized third party might still be able to reverse engineer an app and build an array of attacking “bots” that run compromised versions of the app. This bot array might allow the unauthorized third party to perform unauthorized operations. It would be desirable to make reverse engineering of an app more difficult, preferably without requiring extensive, continual modification to the app or its interfaces.